CU Amiga Super CD-ROM 23

home *** CD-ROM | disk | FTP | other *** search

/ CU Amiga Super CD-ROM 23 / CU Amiga - Super CD-ROM 23 (June 1998).iso / CreatingGames / GameCreators / TADS / manuals / TADSG.DOC < prev next >

Wrap

Text File | 1993-02-16 | 47.8 KB | 974 lines

TADS/Graphic Beta Release Notes =============================== Introduction ------------ Thanks for participating in the TADS/Graphic beta test program! We appreciate your help with our new product testing. Our main goal for the beta test program is to find out what changes we need to make to TADS/Graphic before making it generally available. As you use the software, please make notes of the problems you encounter and the features you'd like to see added or changed. You should look for the following types of things in particular: - Bugs. The most important goal of the beta test is ensuring that the software works correctly. - Performance problems. If you find situations where the system seems to run too slowly, let us know what you're doing. - Missing features. If you need a new feature in the system to make it possible to implement some part of your game, let us know what you're trying to accomplish and what support you'd like from the system. - Changes to existing features. If you find an existing feature difficult or inconvenient to use, give us your suggestions for improving it. - Documentation. If you find parts of the documentation confusing or incorrect, please suggest improvements or corrections. If you find information missing, let us know. To some extent, we'll be able to compile our own list of missing documentation based on your questions, but it would help if you provided your own list. TADS/Graphic Product Disposition -------------------------------- Please keep in mind that TADS/Graphic is *not* yet a product. We hope to release TADS/Graphic as a product in the future, but we can't guarantee that this will happen. We could, for example, decide that we want High Energy Software to devote itself to selling medical insurance, which would make TADS/Graphic somewhat incongruous with our corporate mission. We could also decide that we want to be greedy and not let anyone use our great system to develop games that would compete with our own games. In any case, we're hereby warning you that you must not construe this Beta program as a commitment by High Energy Software to release TADS/Graphic at any point in the future, or to anything else at all, for that matter. Therefore, please do not base any personal or business plans on the existence of TADS/Graphic. For example, please do not yet sell all of your personal possessions so that you can lead an existence devoid of any distractions from developing graphical adventure games with High Energy Software graphical adventure development systems. Also, please do not enter into any contracts with Electronic Arts to deliver a graphical adventure game version of the Sports Illustrated Swimsuit Edition by June 1993 (at least, not if the contract is in some way predicated on the existence of TADS/Graphic at any point in time). If you do any of these things, there's a good chance that you'll want to sue us when we decide not to release TADS/Graphic after all; we just want to make clear up front, for the purposes of defending ourselves at the inevitable legal proceedings, that we didn't say anything that would lead a reasonable person to believe that we really meant we'd make a product out of this pile of code. Also, please note that we do not intend to make TADS/Graphic shareware. Furthermore, the Beta version is not only not shareware, it's actually not even a product! It's a proprietary trade secret of High Energy Software. Therefore, please do not give a copy of the beta software to anyone. Treat it as you would your commercial software (actually, allow us to reword that: treat it as the commercial software vendors want you to treat your commercial software -- but we're sure that's the same thing, so forget we mentioned it). Note that when we say that the Beta version is a proprietary trade secret, we just mean the software. We don't mind if you talk about it with other people, as long as you don't give anyone a copy. In fact, we're going to release a demo game at some point, so we don't consider the existence and some of the details of the system as terribly secret. However, you shouldn't say anything to anyone that leads them to believe that we've made any kind of commitment to releasing TADS/Graphic as a product, for the reasons detailed above. Hardware Requirements --------------------- TADS/Graphic requires an MS-DOS personal computer with 640k of memory (at least 512k available for programs). You will also need a hard disk, although the amount of free space required is largely determined by the size of your game; you will most likely need at least 10 megabytes free prior to installing TADS/Graphic. You must have at least an EGA display adaptor; VGA is strongly recommended. TADS/Graphic will run in the 640 x 350 16-color mode on EGA, but the limited palette available in EGA mode makes EGA less than optimal. It is possible that future versions will support only VGA; already, the "title mode" is 320 x 200 x 256, which is available only on VGA and MCGA (and TADS/Graphic doesn't support MCGA because it doesn't provide a suitable 640 x 480 mode). EGA also has a non-square aspect ratio (your pictures will be vertically stretched out, and the compass rose is a rather uncircular ellipse on EGA). If you wish to play music and/or digitized effects, you must have a SoundBlaster or compatible sound card installed. What is TADS/Graphic? --------------------- TADS/Graphic is a superset of TADS version 2.0 that lets you integrate graphics and sound effects with your games. TADS/Graphic provides a new user interface that uses concepts familiar to users of GUI systems, and makes game play easier through use of a mouse. However, TG (as we'll call TADS/Graphic from now on) is much more than a set of superficial improvements to the TADS run-time user interface. The pictures that you display are not simply fixed, static, inactive illustrations. Pictures can change as the player performs actions that change the game state. Pictures can be used as *input* devices as well: the objects depicted in a picture can be associated with objects in the game, allowing the player to refer to an object simply by pointing at it with the mouse and clicking. Furthermore, the TG user interface features a revolutionary intelligent command builder. Using the mouse, the player can enter commands simply by pointing at objects on the screen and selecting command buttons from a small, easily understood set of basic commands. In fact, the command builder is so smart that standard commands can be entered with just a single click of the mouse! More complicated commands require at most three clicks of the mouse: one on a command button, another on the direct object, and another on the indirect object. The command builder is smart enough to supply any needed prepositions on its own. The best thing about the command builder is that it is constantly aware of the state of the game. Unlike the poor command builders found in other hybrid text/graphics systems, which are little more than gigantic lists of words offered with no knowledge of the game context, the TADS/Graphic command builder monitors the state of the game and offers useful default actions. For example, if the user is pointing at a closed door, the command builder would offer "open door", and the user need only click on the right mouse button to open the door! If the door is already open, the command builder offers "close door". When the mouse is pointing at something that can be picked up, the command builder offers "take". Don't worry, though -- the command builder won't give away any of your secrets. As game author, you have complete control over the defaults that the command builder offers. Of course, we haven't forgotten our text adventure roots. For the die-hard text adventure fan, the full command parser that helped make TADS games so much fun is still available from the command line. And, unlike some other hybrid text/graphics systems that had a mouse-based command builder slapped half-heartedly onto the text parser, TG is non-modal: both the keyboard and the command builder are always active. In addition, TG includes an extended version of ADV.T (called ADVG.T) which provides pre-implemented default graphical interface behavior for the basic adventure classes -- so TG brings the same advantages of object-oriented programming to graphical game design that TADS provided for text adventures. TG provides a set of tools and intrinsic functions that let you integrate the graphical presentation with your game. The programs that make up TADS/Graphic are: - The TADS/Graphic runtime (TRG). This is the extended version of TR that provides the new graphical intrinsic functions and a graphical user interface. - The TADS/Graphic compiler (TCG). This version of the TADS Compiler reads not only your game source (.T) files, but also your TG resource files. This means that your game source and resource files are *automatically* integrated by the compiler. - The TADS/Graphic Room Editor (TGE). This resource editor allows you to associate a picture with each room in your game, create and modify "hot spots" (which associate a section of a picture with a game object), and generate "overlays" (sections of a picture which are separated into their own picture files, so that they can be edited and changed independently of the main picture and later displayed on top of the original picture, thereby changing the picture as the state of the game changes). - The TADS/Graphic Icon Editor (TGI). This resource editor allows you to associate an icon with each item in the game that the player can take and put in the inventory. These icons are displayed in the inventory window to help the player keep track of the objects currently being carried. Can people play TADS/Graphic games without an EGA or VGA display? ----------------------------------------------------------------- One very interesting feature of TADS/Graphic is that the games you design with TG are supersets of the games you would design with TADS. As a result, you can run any TADS/Graphic game with the standard TADS run-time (and you don't even need to recompile)! Therefore, in theory, people *can* play your games on a monochrome display, or on any other display, without any graphics. (Note that playing a game with the standard text-mode TADS Runtime also removes the sound capability, even if a sound card is installed.) Some cooperation from you, the game author, is required if your game is to be played without graphics. There is nothing special you need to do during implementation -- the cooperation is required at the *design* level. Specifically, you must take care that your game doesn't require the pictures -- no vital information should appear in the pictures that doesn't also appear in the accompanying text. All this really means is that you must make sure that you faithfully describe anything important that appears in the pictures in the textual room descriptions. Now, it's certainly not *required* that you make a game that's playable in pure text mode. However, if you are interested in making all-text play possible, just keep text mode in mind while designing the game and writing the room descriptions. What do you need? ----------------- In addition to the TADS/Graphic package, you'll need tools to create sound effects, music, and pictures. The TG package does *not* include any painting/drawing tools, music editors, or digitized sound recorders. Instead, TADS/Graphic reads files stored in specific standardized formats, so you can use any third-party tool that creates files in the appropriate formats. Graphics: TADS/Graphic reads 16- and 256-color PCX files. (In addition, TGE creates overlay files in 256-color PCX format, and TRG reads them back in this same format.) The picture that TADS/Graphic displays in the graphic window while in normal graphics mode is a 320 (horizontal) by 200 (vertical) pixel pictures. TRG will read 16- or 256-color pictures, but always converts the pictures to 16-color format for display; you should therefore draw pictures that use no more than 16 colors (but you can choose the 16 colors from the full VGA palette, and each picture can use a different palette). We chose PCX format because it supports a full VGA palette, it provides flexible picture sizing, and nearly all PC paint and drawing programs can read and write PCX files. Music: TADS/Graphic plays SoundBlaster .CMF files. You must have a music editing program that is capable of producing this format. Note that you can convert files from a variety of other formats into .CMF files; for example, if your composition software saves files in the popular .ROL format (used by the AdLib card), you can use a conversion utility to generate a .CMF file from the .ROL data. Several conversion tools are available free from the Creative Labs BBS and other on-line sources. Sound Effects: TADS/Graphic uses SoundBlaster .VOC files for digitized sound effects. The SoundBlaster card comes with bundled software that allows you to create files in this format. Note that you can generate a .VOC file from a variety of other digitized sound formats; for example, sound resources generated on a Macintosh can be easily converted to a .VOC file. Several conversion tools are available free from the Creative Labs BBS and other on-line sources. Text Editor: As with TADS itself, you will need a text editor that produces plain ASCII files to prepare your source files. Getting Started --------------- ** Step 1: Design and start writing your game. The first thing you need to do is to design your game just as you would a normal TADS game. In fact, there are very few differences between writing the .T file describing a normal text-only TADS game and a TADS/Graphic game. Practically the only difference is that you should use the single-quoted string property gp_name instead of sdesc whenever you define an object that can either be taken or will appear in a room's picture. (Why? Because the command builder needs to know the name of an object when the player places the mouse over it. What about the sdesc? You don't need one if you define gp_name! ADVG.T defines sdesc = { say(self.gp_name); } for all objects. But, you can *also* define an sdesc if you want -- if you define your own, it will override the default, so you can make the name that shows up in the command builder different from the sdesc if you want.) Note that you should #include the graphical versions of the standard files. Use ADVG.T instead of ADV.T, and use STDG.T instead of STD.T. ** Step 2: Add icons for movable objects. The next thing you need to do is to provide an icon for each object that can be picked up by the player. The icon is displayed in the inventory window when the player is carrying the associated object. Using the icon editor is quite simple. If your game's main .T file is called SAMPLE.T, call your icon resource file SAMPLE.TI. Run the icon editor like this to create or edit the file: tgi sample.ti This brings up a screen that shows a list of objects (empty if you're starting a new .TI file) and an icon. To create a new icon, click on the "New" button and enter an object name -- this is the object defined in your .T file with which you want to associate the icon. (If you've used resource managers for other systems, it might be occurring to you now just how nice TADS/Graphic programming is going to be in comparison. Did you notice that the icon has a *name*, not a number? You'll notice soon that this operation -- naming the icon in the .TI file -- is the *only* thing you have to do to associate the icon with the object. You won't need to make any corresponding entry in your .T file -- the compiler will automatically add the necessary information to the TADS object when you compile your game! No, the compiler doesn't modify your .T file -- it just stores the icon information for the object in the .GAM file.) Now you can turn pixels on and off in the big icon picture at the top of the screen. Clicking the mouse inverts a pixel; holding down the button and moving the mouse around keeps changing pixels to the color to which you changed the first pixel. The icon editor is pretty simple and primitive - that's pretty much all it does. ** Step 3: Draw your room pictures. This step is easy for us to say, and time consuming for you to do. Start up your favorite paint program and draw a 320 x 200 picture depicting the first room in your game. Save the picture in PCX format. Rinse. Repeat for each room in your game. Note that you should be careful not to use more than 16 different colors in your pictures, because the TADS/Graphic run-time runs in the EGA and VGA 16-color modes. The Super VGA 640 x 480 256-color modes are too slow and non-standardized for us to support them at the moment. However, you can choose your 16 colors from the full VGA palette. (You don't have to worry about making the pictures perfect right now, because you can go back and edit the pictures at any time. There's no point where you have to "import" the pictures into TG -- the pictures are automatically read from the .PCX files while the game is actually running. So, when you change a picture, you don't even need to recompile your game. Note, however, that you may have to adjust the hot spots defined for a picture; hot spots are describe more fully later.) ** Step 4: Add the pictures to the game. Now it's time to create the Room resource file. This is similar to the Icon resource file; you use the TADS/Graphic Room Editor, TGE, to operate on this file. Call it SAMPLE.TG, and create and edit it like this: tge sample.tg This brings up a screen very similar to the Icon Editor screen, but a bit more complicated. On the top of the screen is a blank area -- TGE will use this area to display the current room's picture. On the bottom you'll see two list boxes. The first is a list of rooms, and the second is a list of "regions" within the current room. There are also some buttons for creating overlays. Now, associate a picture with each room. Click on the "New" button. Enter the object name for a room (this is the same name that you use in your .T file when defining the room object), and enter the name of a .PCX file that you want to associate with the room. As with the icon editor, this is the only thing you need to do to associate a picture with the room -- the TADS/Graphic Compiler automatically adds the necessary information to your .GAM file, so you don't need to manually add anything to your .T file to tell the system what picture to use. ** Step 5: Compile the game. This is easy: just use TCG as though it were TC. TCG takes all of the same options as TC. For the simple case, all you'd have to do is something like this: tcg sample Note that TCG automatically derives the resource filenames from your source filename. So, when you compile SAMPLE.T, the compiler will look for SAMPLE.TI and SAMPLE.TG in the same directory as SAMPLE.T. If the compiler can't find the resource files, it will display a warning. In addition, if your resource files refer to objects that aren't defined in your .T file, the compiler will issue a warning message. Note, however, that there's no warning for *failing* to provide an icon or picture for an object, because the compiler doesn't have any good way to know if an object should have resource data or not -- it's up to you to make sure that each object has the necessary resource associations. ** Step 6: Run the game. Use TRG to execute the game: trg sample The TADS/Graphic interface will come up, and your game should display its introductory text and display the first room's picture. Going Further -- Regions ------------------------ So far, we've just made an illustrated text adventure. The pictures that you defined for your rooms don't do anything -- they just sit there making the game prettier. However, TADS/Graphic lets you do much more with your pictures: you can change a picture's appearance as things depicted in the picture change; and you can make the picture active, so that the player can do things to objects in the picture simply by pointing at them with the mouse. This is all accomplished through "regions." A region, or "hot spot," is a rectangular area of a picture that you associate with a game object. For example, a picture might depict a shelf; you could define a rectangular area around the picture of the shelf to be associated with an object in your .T file called "shelves". This assocation is made with the Room Editor. First, bring up TGE with your room resource file. Select the room containing the shelves by clicking on its name in the room list; this will select the room and display its picture. Now, go over to the region list, and click on the "New" button. The mouse will immediately change to crosshairs and move to the picture area. Drag the mouse over the rectangular area you wish to associate with the "shelves" object: move the mouse to the upper left, click and hold down the mouse button, move to the lower right while still holding down the button, then release the button. A highlighted rectangle will appear over the area you defined. Now the system will ask you to enter the name of the object you're associating with the region. You can move and resize the rectangle for a region at any time. First select a region by clicking on its name in the region list. Move the rectangle by clicking in the middle of it, holding down the mouse while dragging the rectangle to its new location, and releasing the mouse. Resize the rectangle by dragging its lower right corner. Now you can recompile and run your game. When you go into the room with the hot spot, and move the mouse over the hot spot, the command builder window should automatically show a default command for the shelves! You can execute the default command by clicking the right mouse button. You can simply select the object for another command by clicking the left mouse button -- then you can click on a verb button to execute a different verb on the object. Going Further Still -- Overlays ------------------------------- The next step in writing your game is to make your pictures change in response to the player's actions. For example, when the player picks up an object shown in a picture, the object should be removed from the picture. Or, when the player opens a door, the picture should reflect the change. The first thing to do is to make a hot spot for the area to be changed, as described earlier. Select the hot spot by clicking on its name in the region list. Now, click on the overlay button that matches the type of region: Item - something on the screen that should go away when the user picks it up Openable - something that should change when the user opens and closes it Other - any other type of changing picture area The editor will ask you for a picture filename. Enter just the *root* filename: seven letters or fewer. The reason you enter just seven letters is that the editor is going to create two files whose names are formed by appending some more letters to the filename root you provide: Item - <rootname>T.PCX for the "taken" (object not present) overlay <rootname>D.PCX for the "dropped" (object present) overlay Openable - <rootname>O.PCX for the "open" overlay <rootname>C.PCX for the "closed" overlay Other - <rootname>1.PCX and <rootname>2.PCX, to be used according to your needs The editor will create the files by writing a small picture containing only the area contained in the region rectangle. After you've created the necessary overlay files, exit TGE and start your favorite paint program. For each overlay, you'll probably only need to change *one* of the two overlay files -- the other is simply used to restore the original information if you want to remove an overlay. NOTE 1: Your paint program *must* be able to store the .PCX file in its original size. Some paint programs instead store the .PCX file in full-screen size. NOTE 2: When defining an overlay for an item that can be taken, you must draw the original room picture with the item *missing*, and add the item to the <rootname>D.PCX overlay picture. The reason is that TADS/Graphic applies item overlays according to the objects that are actually present in a room. So, while an object is present in its original location, the <rootname>D.PCX is drawn. When an object is first taken, the <rootname>T.PCX overlay is applied. However, once an object is gone, and the player enters the room later, no overlay at all will be applied! Since overlays are applied according to a room's contents, an overlay can't be applied for an object once it's been removed. Hence, you must draw each room as it will look after all items that can be removed have been removed. Command Builder Interface ------------------------- The TADS/Graphic command builder achieves its exceptional integration with the game using a mechanism very similar to the interface between the regular TADS command parser and a game. The command builder uses a series of special properties provided by the objects in your game program to determine what types of commands to build. The first thing that the command builder needs to know is which objects are in a room. This information is available from the hot spot data that you create with the Room Editor. When the compiler reads your game program, it adds the hot spot information from the room editor resource file (the .TG file) to each room in your game. The TADS/Graphic Run-time reads this information each time the player enters a new room, and makes it the "current" hot spot list. The run-time now has a list of regions on the screen and objects to which those regions correspond. When the player moves the mouse over one of these regions, the run-time system checks a number of properties in the object, and builds a command based on that information. First, the run-time calls the object's gp_active method. This method returns true or nil, indicating whether the object's hot spot should be considered active by the command builder. If gp_active is nil, the command builder ignores the hot spot, and no command is built for the object. If gp_active is true, the command building process continues. Next, the command builder evaluates the object's gp_name property. This property returns a (single-quoted) string indicating the name of the object as it should be entered in a command. This should include any adjectives and nouns needed to identify the object uniquely within the game. Next, depending on the current command building state, the properties gp_defverb and gp_defverb2 are evaluated. These properties return strings indicating the default verbs that should be applied to the object. The property gp_defverb returns the default single-object verb to be applied to the object (a single-object verb is a verb that takes only a direct object, and no indirect object). The property gp_defverb2 returns either nil or the default two-object verb of which the object is the indirect object. If gp_defverb2 returns a non-nil value, it takes precedence over gp_defverb. For example, if a simple item that appears in a picture would normally return gp_defverb = 'take' and gp_defverb2 = nil. This means that the default command for the object is "take item". A simple fixed item that appears in a picture would normally return gp_defverb = 'examine' and gp_defverb2 = nil. A fixed item that is also an openable would return gp_defverb = 'open' if the object is closed, and gp_defverb = 'close' if the object is open. It may also be desirable to return gp_defverb2 = 'put in' when the object is open, because it can act as a container. When gp_defverb2 returns 'put in' rather than nil, the gp_defverb value is ignored, and the default command for the object is "put _____ in item". The blank can then be filled in by the player by selecting a second object (such as an item in the inventory window). As with most things in TADS, a suitable set of command builder properties is inherited by most objects. You'll only need to provide your own overriding definitions for gp_defverb and gp_defverb2 when you create a new kind of object. Note that gp_name should be used in place of sdesc when defining objects in a TADS/Graphic game. The base class thing in advg.t provides a definition for sdesc = { say(self.gp_name); }, so you do not need to provide an sdesc for an object unless it differs from the gp_name. New Built-in Functions ---------------------- g_readpic(filename). The filename is a (single-quoted) string giving the name of a PCX file. This file is read into a "staging area" that holds the current room picture under construction. The display is *not* changed by g_readpic; you must call g_showpic to display the current picture. No return value. g_showpic(). Displays the current picture, replacing whatever is currently displayed in the picture area (or the entire screen, if in title mode). Sets the palette for the new picture prior to displaying the picture. No return value. g_sethot(hotlist). Sets the current room's hot list data. This will almost never be called except by the low-level room entry functions in advg.t; the only valid argument for this function is the value of a gp_hotlist property inserted into a room by the compiler based on information in the room resource (.TG) file. No return value. g_inventory(nil). Clears the entire inventory window. No return value. g_inventory(obj, in_inventory). Adds or removes obj from the inventory window. If in_inventory is true, the object is added (but the call is ignored if the object is already present -- an object can't appear in the inventory window twice); if in_inventory is nil, the object is removed (but the call is ignored if the object is not in the inventory window). Note that this function will not normally be needed by a game program except in the low-level functions in advg.t, since the normal inventory management routines in advg.t keep the inventory window synchronized with the game under most circumstances. You'll only need to code calls to this routine explicitly when you do something that circumvents the normal inventory management routines. No return value. g_compass(direction, enabled). The direction is a number: 1 = North, 2 = Northeast, 3 = East, and so forth around the compass clockwise, through 8 = Northwest; 9 = Up, and 10 = Down. If enabled is true, the given compass point button is enabled (that is, the button is turned white, and may be selected by the player). If enabled is nil, the given button is disabled (it is turned gray, and clicking on the button with the mouse has no effect). There is no return value. g_compass(direction_list, enabled). The direction_list is a list of numbers corresponding to the compass direction buttons as described above. The buttons indicated in the list are enabled or disabled according to the value of enabled, and in addition, all of the compass buttons *not* in the list are set to the opposite value. For example, g_compass([1 3 5 7], true) enables north, east, south, and west, and disabled northeast, southeast, northwest, southwest, up, and down. This form of the call allows the entire compass to be set up with a single call. Note that the single-button form can be used after a list call to further modify individual buttons. This function returns no value. g_overlay(filename, x, y). Reads the PCX file given by the (single-quoted) string filename, and writes the contents of the file over the current room picture starting at the given (x,y) coordinates. Note that this function does *not* change the display -- it simply modifies the current room picture under construction. You must call g_showpic() after all overlays have been applied to change the display. This function returns no value. g_mode(mode). Sets a display mode. The display is immediately changed to the selected mode. No value is returned. The valid values of mode are: 1 Normal game mode. The display is put into 640 x 480 x 16 mode (640 x 350 x 16 on EGA). The top left quadrant of the screen displays the room picture; the top right quadrant displays the controls (command buttons, compass, inventory window, command builder window). The bottom half of the screen is devoted to the text window. This is the mode for normal interactive game play. 2 Title mode. The display is changed to 320 x 200 x 256 mode (VGA only - no effect on EGA). The entire screen is devoted to the current picture. This mode can be used to display titles and special sequences, but note that no interaction is supported in this mode. g_music(filename). The CMF file indicated by the (single-quoted) string filename is read into the music buffer, and becomes the currently active music track. The music is played continuously in the background until another call to g_music(). Any music previously playing is stopped and replaced with the new music file. There is no return value. g_sound(filename). The VOC file indicated by the (single-quoted) string filename is read and played. The sound file must be less than 64k long. There is no return value. This function does not return until the digitized sound has finished playing. If any music is currently playing, the music will continue while the digitized sound plays. g_pause(delay). Pauses for the indicated delay, which is a number specifying hundredths of seconds (to pause for 5 seconds, use a delay value of 500). If the user hits a key or clicks the mouse during the delay interval, the delay is immediately ended (this allows players to skip ahead during title or special sequences that they've already seen or have finished looking at before the alloted delay). There is no return value. g_effect(num). Applies a special display effect. There is no return value. The effect is applied immediately. These effects are intended to be applied in title mode (g_mode(2)) only, because they apply to the entire display. The valid values of num are: 1 Fade in from black to current picture. The display is set to an all-black palette, the current picture (read with g_readpic and possibly modified with g_overlay) is displayed, then the palette is gradually changed from all black to the current picture's palette. 2 Fade from current picture to black. Reverses the effect of 1. 3 Fade in from white to current picture. Similar to 1, starting with an all-white screen. 4 Fade from current picture to white. Reverses the effect of 3. 14 Dissolve into new picture. The picture currently on the screen is gradually replaced with the picture in the staging area (read with g_readpic and possibly modified with g_overlay). The palette is *not* changed during the transition, so the two pictures must share a common palette. New System-Defined Properties ----------------------------- gp_name: returns a single-quoted string value indicating the name of an object to be used by the command builder. gp_defverb: returns a single-quoted string value indicating the default single-object (i.e., direct object only) verb to be offered when the object is selected with the mouse. gp_defverb2: returns a single-quoted string value indicating the default two-object verb to be offered, with this object as indirect object, when the object is selected with the mouse. Returns nil if there is no default two-object verb. gp_defprep(verb): verb is a single-quoted string indicating a verb under consideration by the command builder. Returns a single-quoted string indicating the default preposition that should be applied if this object is to be used as the indirect object of this verb. For example, a surface would return 'on' if the verb were 'put', whereas a container would return 'in'. This property should simply return nil if the object doesn't make sense as the indirect object of the verb. gp_active: returns true if the hot spot corresponding to the object should be considered active by the command builder, nil otherwise. gp_hotlist: this property is set by the compiler during integration of the room resource (.TG) file. This property should not be set by your code. gp_icon: this property is set by the compiler during the integration of the icon resource (.TI) file. This property should not be set by your code. The value of this property is used by the run-time system to extract the icon to be displayed in the inventory window for the object. gp_hotid: this property is set by the compiler during integration of the room resource (.TG) file. Your code should not set this property. The property is set for each object used in a hot spot to identify the hot spot. The value is a list. The first element is the room object with which the hot spot is associated. The second element is the index within the room's gp_hotlist data of the hot spot information for this object. This property is not currently used, but may be used by future intrinsics. gp_overlay: this property is set by the compiler during integration of the room resource (.TG) file. It should not be set by your code. This property contains a single-quoted string value that gives the prefix name of the PCX file containing the overlay for the object. This is simply the prefix name that you enter with the "create overlay" dialog box in the room editor. This information can be used by your game program to load the various overlay files associated with the object, without having to include the actual name of the file in your game (this feature is used by advg.t, for example, to provide a simple mechanism for applying overlays when objects are opened and closed, or taken, without any coding in your game). gp_hotx and gp_hoty: set by the compiler during integration of the room resource (.TG) file. These properties provide the (x,y) coordinates of the overlay corresponding to the object. Used in conjunction with gp_overlay to apply the overlays for an object to the room picture. Questions and Answers --------------------- - Okay, how many colors do I *really* have? You really have 16 colors, but two of them are reserved: you must always have one color that is pure black, and another that is pure white. So, your pictures are composed of 14 colors that are entirely of your choosing (the system doesn't care at all what these other colors are), plus 2 fixed colors: black and white. The system reserves black and white so that it can draw the control panel area consistently for every room, regardless of the palette for any particular room. The disadvantage of this is that you get only 14 colors you can truly choose; the advantage is that every room can have its own unique palette without having the controls change in every room. - Why are the icons monochrome? The icons (and, in fact, the entire control panel area) is monochrome so that we didn't have to either reserve a bunch of colors for the control panel, or make the control panel keep changing colors every time the room picture palette changes. The TADS/Graphic system demands that black and white are always in the palette. Since the icons are displayed independently of the rooms, and it's undesirable for the icons to change colors every time the player enters a new room, the icons must be drawn with the fixed, room-independent colors: black and white. - Can I define multiple icons for a single object? For example, I want to depict a box differently when it's opened and when it's closed. You can't do this directly, because the icon editor allows only a single icon to be associated with each object. However, you can define a dummy object in your game whose only purpose is to hold icon data in its gp_icon property, and then assign this icon data to the object whose icon you want to change. For example, let's assume you've defined a dummy object named box_open_icon_holder, and associated the opened version of the icon with this object; then, in your box's doOpen routine, you could do this: self.closed_icon := self.gp_icon; // save icon when I'm closed self.gp_icon := box_open_icon_holder.gp_icon; // switch icons if (self.isIn(Me) and self.isVisible(Me)) { g_inventory(self, nil); // remove my icon from inventory window... g_inventory(self, true); // ... and add it back to ensure refresh } Likewise, your doClose method would do this to restore the original icon: self.gp_icon := self.closed_icon; // restore closed icon if (self.isIn(Me) and self.isVisible(Me)) { g_inventory(self, nil); // remove my icon from inventory window... g_inventory(self, true); // ... and add it back to ensure refresh } - How can I have multiple hot spots for a single object? How about multiple overlays? For example: I want to have a ladder start off in one room (so it needs an overlay and hot spot there), but I want the player to be able to pick it up and carry it to another room, where it will need another overlay and hot spot. Things won't work properly if you try to define two hot spots for the same object, thanks to the one-to-one relationship between hot spots and game objects. You'll need to use another trick like the one that lets you create multiple icons per (apparent) object, described above. For example, suppose you want to use the ladder to climb up to a hole in the ceiling, and let's say that the command needed is simply "drop ladder" in the appropriate room. You could write a doDrop method for the ladder that checks to see if the player is in the special location with the hole in the ceiling, and if so, switch the original ladder with a second ladder object. Note that, unlike the icon switch method, you'd actually switch the object itself rather than just some property of the object. The ladder.doDrop method might look like this: doDrop(actor) = { if (actor.location = holeRoom) { "%You% put the ladder under the hole. It looks like %you%'ll be able to reach the hole easily now."; self.moveInto(nil); /* to make sure overlay is displayed */ ladder2.ismoved := nil; ladder2.moveInto(actor.location); } else pass doDrop; /* use default doDrop anywhere else */ } Note that the moveInto routine in advg.t will take care of displaying the picture of the new ladder object in its new location. This is done automatically because ladder2 has never been taken (whenever an object is picked up, its property ismoved is set to true; by setting ismoved to nil before calling moveInto, we ensure that moveInto knows that the ladder is being moved back into its original location). Note that you'll have to also define a doTake method in ladder2 that undoes these changes. All it needs to do is restore the original ladder to the player's inventory; ladder2.doTake might look like this: doTake(actor) = { "Taken."; self.moveInto(nil); /* automatically removes ladder from picture */ ladder2.moveInto(actor); /* automatically updates inventory window */ } You can use similar tricks for a multitude of effects requiring the same object to have multiple icons, hot spots, or overlays. - That's all well and good, but what about the more general case? What if the player picks up an object in one room, and drops it in another room? What will the system display in the new room? Simple: nothing. The only way to make an object show up in a room is to draw an overlay for it in that room, and associate that overlay with that object's hot spot. If the player drops an object in the room where it started, the original overlay for the object in that room will be redisplayed. If the player drops an object in another room, unless you've specially set up another picture of the object in its new room as described above, the object will simply not appear anywhere in the picture. Of course, it will still appear in the textual description of the room, so it doesn't disappear from the game entirely; and the player can still manipulate it with typed commands (but not with the mouse or the command builder, since there's nothing to point to). - Why don't you display the object's icon, or make a "generic" overlay for each object that's displayed whenever it's in a non-default location? Because it would look stupid. - But wouldn't that be better than removing it from the picture altogether? Not at all. Here's my question: why would the player ever need to drop anything in general, when there's nothing to be gained by doing so? (I'm not talking about situations like dropping the ladder under the hole -- that's covered by explicit extra programming to handle the object being dropped in a special context, which you'd want anyway even if the system did have some sort of general object depiction capability. I'm just talking about randomly dropping an object in a location where it will do no particular good.) Well? - Lots of reasons! First, what if the player is carrying too much stuff and wants to drop something? Or, maybe the player is going through the game trying to find weaknesses in the interface so they can post flames all over usenet! For the first situation, it's easy: get rid of the inventory bulk and weight limits. There's no good reason for these except that lots of text adventures have them. Inventory management in general just isn't that interesting a puzzle; when you want to create some specific inventory management puzzle (such as: you can't get the xenite crystals too close to the radioactive frobnezium rods, so you can't carry them both at the same time unless the frobnezium is in the lead box), you can set things up so that either there's a good place to deposit one of the objects (so you program in a special case as with the ladder), or there's some solution other than dropping objects (such as a lead box to shield the xenite from the deadly M-rays). Note that the default basicMe weight and bulk limits have been raised to absurd new highs to prevent any need for the player to think about inventory management. You can change them back if you want, but why would you want to? For the second, who cares? A determined detractor will find lots of problems with your game no matter how thorough you are. Your workload for writing a graphical game is going to be sufficiently high that it's not worth the effort to address issues that don't add to the playability. Realism isn't the highest goal in writing a game -- playability is. Games are supposed to be fun! Is chess realistic? Is poker realistic? Is any adventure game you've ever played realistic? Of course not. It's not a tractible problem to make a realistic game, and if you did there's no reason to think it would be all that much fun anyway. If you don't give players a reason to drop objects, very few of them will ever try to drop objects. Those that do will discover a minor limitation of the game. In fact, you might even want to simply make it impossible to drop objects by turning off the generic "drop" command altogether. You'll notice there's not even a "drop" button on the main control panel.